Intrusion Detection Systems (IDS) are rule-based security controls designed to monitor a system or network for suspicious activity. When suspicious activity is detected, an IDS will generate alerts to the system administrator. Most IDS solutions are also capable of functioning as Intrusion Prevention Systems (IPS), which will actively block the suspicious activity, rather than simply report it. In practice, IDS/IPS's are typically configured to send their alerts to Security Information and Event Management (SIEM) systems, which aggregate security alerts from multiple systems in a centralized interface that security analysts can easily monitor.
There are two types of IDS/IPS - network-based IDS/IPS (NIDS/NIPS) and host-based IDS/IPS (HIDS/HIPS). As the name implies, an HIDS/HIPS is designed to monitor a single host, while an NIDS/NIPS is designed to monitor an entire network. NIDS/NIPS are typically integrated with modern firewalls, where they can easily monitor all traffic that passes through the firewall. It is also common for an IDS to have a primary server in one central location and multiple sensors in other subnets that then forward findings to the primary server.
The two most popular NIDS/NIPS solutions are Snort and Suricata. Both packages can be installed on stand-alone Linux systems and are integrated into popular firewalls like pfSense, Smoothwall, and OPNsense. Both Snort and Suricata use the same kind of rules (called signatures), are multithreaded for performance and resilience, and can operate in different modes (intrusion detection, logging, and sniffer). The focus of this lab will be on Snort.
Snort rules can look a little strange at first, but the basic syntax is pretty straightforward. A Snort rule is made up of a header section and an options section. The header section reads a bit like a firewall rule, and the options section can be as simple as a message and a sid (a unique identifier).
Header: alert tcp 10.10.10.1 any -> 10.10.10.100 21 / Options: (msg: "User has accessed FTP"; sid: 00001;)
In the example above, Snort will alert when host 10.10.10.1 (the source) tries to touch TCP port 21 on host 10.10.10.100 (the destination). The source is always on the left and the destination on the right. Notice the -> which is the flow indication (from source to destination). The sid (Snort ID) can be any numeric value, but all sids in a rule file must be unique. The message (msg) is simply what gets logged when this alert happens. You can write any message you like, but it should be related to the traffic rule to be useful.
In Snort, rules often look in both directions:
Header: alert tcp any any -> any 25 / Options: (msg: "SMTP Detected"; sid: 00002;)
Header: alert tcp any 25 <> any any / Options: (msg: "SMTP Detected"; sid: 00003;)
In the above example, Snort will detect TCP 25 (typically used for SMTP messages) from any source to any destination, and then from any destination to any source. Notice there is no <- flow indication; <> is used to indicate both directions.
Snort is also capable of reading the contents of a packet and sending alerts if a matching pattern is found:
alert tcp any any -> any any (msg: "Botnet Detected"; content: "|5a 4f 4f 4d 00 00|; sid: 00002
In the example above, we are using the content option to find the hex string "5a 4f 4f 4d 00 00" in any TCP traffic. This string's presence indicates that the Zeus botnet exists on your network. If you have seen production class Snort rules in the past, then you know the options section can get pretty involved. There are a lot of options and many different ways to use them. Even security experts don't always agree on the "best" way to hunt for a given evil using the options syntax. With that in mind, we will keep the options used in this lab fairly simple for learning purposes.
In the next steps, you will start Snort from the command line and acquaint yourself with its interface. If you haven't already, click the Start Lab button to launch the lab environment.